The :focus pseudo-class applies styles whenever an element receives focus, regardless of how the focus was triggered (keyboard, mouse, or script). In contrast, :focus-visible applies styles only when the browser determines that focus should be visibly indicated, typically for keyboard navigation.

Key Differences

1
:focus – Styles any element that has focus, triggered by any method.
2
:focus-visible – Styles elements only when focus should be visibly indicated (usually keyboard or accessibility-related interactions).
3
Using :focus-visible prevents unnecessary focus styles when clicking with a mouse, improving UX.
4
:focus-visible respects user preferences and accessibility guidelines.

Example: :focus vs :focus-visible

In this example, when you click the button with a mouse, only the :focus style may apply depending on browser defaults. When you navigate to the button using the keyboard (Tab key), the :focus-visible outline appears, providing a clear visual indicator for keyboard users without distracting mouse users.

Best Practices

1
Use :focus-visible to provide focus indicators for keyboard and accessibility users without affecting mouse interactions.
2
Combine :focus and :focus-visible for consistent and accessible focus styling.
3
Test on multiple browsers, as :focus-visible support varies and may require a polyfill in older browsers.
4
Maintain sufficient contrast and visible indicators to meet accessibility standards.

Difficulty: 6/10

Topics: focus styles, accessibility, user input detection

Scenario Questions

0-2 years experience

1
You're building a form and notice the input outlines disappear when clicking with a mouse, but reappear when tabbing — how would you fix it so keyboard users still see focus indicators?
2
A teammate says 'just use :focus { outline: none; }' to clean up the look — what’s wrong with that approach and what should you use instead?

2-5 years experience

1
Our modal dialog works fine with keyboard navigation, but users complain the focus ring is too aggressive when clicking buttons — how would you debug and fix this without breaking accessibility?
2
After updating our button component, screen reader users report they can't tell which element has focus — what might have changed, and how would you verify it's fixed?

5-8 years experience

1
We're redesigning our design system and want to remove all default browser outlines — how would you architect a focus style system that supports both mouse and keyboard users across 50+ components without regressions?
2
A third-party library we use overrides :focus-visible with !important — how do you detect and mitigate this without modifying the library, and what long-term risks does this introduce?

8+ years experience

1
Our legacy app has 200+ components using custom focus styles — how would you plan and execute a migration to :focus-visible without breaking accessibility audits or user workflows across different devices and assistive tech?
2
As head of accessibility, you're asked to approve a design that hides all focus indicators unless the user is on a keyboard — how do you evaluate this tradeoff across global user bases with varying input methods and legal compliance requirements?

Follow-up Questions

❓How would you test that your focus styles aren't breaking keyboard navigation?
❓What happens if you remove :focus entirely and only use :focus-visible?
❓Can you think of a component where :focus-visible might cause confusion for users?